Date: Tue, 25 Jan 94 04:30:08 PST From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #21 To: tcp-group-digest TCP-Group Digest Tue, 25 Jan 94 Volume 94 : Issue 21 Today's Topics: AMPR and Fully-Qualified Domain Names (2 msgs) e-mail address of PA3EFU/VK3CEX GPIB and packet help understanding the division point of protocol vs app (2 msgs) ping-pong convers for Linux FTP site gone ? TCP MSS and TCP WIN settings (2 msgs) TNC3s information Unclear about MTU in attach... Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Mon, 24 Jan 94 09:21 PST From: bruce@pixar.com (Bruce Perens) Subject: AMPR and Fully-Qualified Domain Names To: tcp-group@ucsd.edu The SMTP servers of our local NOS systems identify themselves using their host names without the ampr.org extension. Some of them refuse to accept mail with the ampr.org extension. For instance, my neighbor Dennis runs PA0GRI NOS 2.something. I tried a few addresses on his SMTP server and got this response: RCPT TO: Works RCPT TO: No such address. RCPT TO: Works RCPT TO: No such address. This system is configured as hostname "ccwest.n6ng", domainname "ampr.org". I'm somewhat confused regarding the use of "ccwest.n6ng" as a host name since I would read n6ng as a sub-domain in this example. This last address above is very distressing, as that is the one I would like to use. Also distressing is the fact that incoming SMTP connections from AMPR identify themselves with their host names alone without the ampr.org extension. I have to run a hack using the internet address to determine if I should tack ampr.org onto those addresses. My local address coordinator says Brian Kantor told him it _should_ be this way, and that an internet mail gateway must add ampr.org to mail in the ampr->internet direction and strip off ampr.org in the other direction. He explained that this was due to the lack of domain name service on AMPR. So, is the problem a continuing lack of domain name service, is it simply broken software, or something else? Can anyone supply a good explanation? Thanks Bruce Perens AB6YM -- Bruce Perens AB6YM Bruce@Pixar.com 510-215-3502 ------------------------------ Date: Mon, 24 Jan 1994 18:52:30 -0800 From: brian@nothing.ucsd.edu (Brian Kantor) Subject: AMPR and Fully-Qualified Domain Names To: tcp-group@ucsd.edu In article Bruce wrote: 1> RCPT TO: Works 2> RCPT TO: No such address. 3> RCPT TO: Works 4> RCPT TO: No such address. ALL of the above RCPT-TO addresses would work if CCWEST.N6NG.AMPR.ORG were running a properly-configured and reasonably flexible mailer. However, it is arguably true (RFC1123) that only the LAST of these, which is the only address that includes a Fully-Qualified Domain Name, is 'correct'. It's conceptually simple: hosts sending mail outside of a domain must be sure that the FQDN is in the address of the mail. Early documents suggested that common parts of the FQDN could be omitted. That proved to be such a bag of worms that nearly everyone agrees that you should always include the full hostname. In this case, 'n6ng.ampr.org' is the domain enclosing the host 'ccwest' - although because we don't delegate domains in the ampr.org domain, it could also be viewed as a complex hostname of 'ccwest.n6ng', which is probably why #3 above works. There are some tightly-controlled domains where it might be permissable to bend the "use FQDNs everywhere" rule slightly by not using any qualified hostnames at all internally, but making sure that mail always passes through gateways between the "internal" network and the outside world that do the proper qualification. In the AMPR world, I suspect that we can't do that. Our domain is not tightly-controlled, there are a lot of broken and half-assed mailers out there, and the "internet-mailer-competency" of many host operators is hardly assured. Best to do FQDN whenever we can. - Brian ------------------------------ Date: Mon, 24 Jan 1994 15:20:29 +0100 From: adam@igg.tno.nl (Adam van Gaalen PA2AGA) Subject: e-mail address of PA3EFU/VK3CEX To: tcp-group@ucsd.edu Hello all, Sorry to bother all of you, but I saw a note from Jan Jaeger PA3EFU/VK3CEX in tcp-group digest number 20... It has been long since Jan and I talked together so I thought I might try to catch up over e-mail... The only thing I need now is his internet-address... PSE HELP! 73 de Adam van Gaalen (adam@igg.tno.nl) ------------------------------ Date: Mon, 24 Jan 94 18:40:06 GMT From: Jan Schiefer Subject: GPIB and packet To: TCP-Group@UCSD.EDU Some days ago I suggested the use of GPIB/HPIB/IEC625/IEEE488 for use with packet radio and asked for feedback. I'd like to summarize the replys I got. The overall perception was that it would not be wise to use an interface that is not available on Joe Ham's PC. Some suggested SCSI as an alternative. I see the point, but in the end you do not want to share the bus you attach your network controller to with devices like harddisks. So you end up having an (expensive?) SCSI controller especially for packet. The general opinion seems to be that it might be technically nice, but not suitable for general use unless you have got a GPIB interface anyway. If you own a PC running DOS, you might prefer an SCC-card and forget about external controllers. If it doesn't run DOS, or it is not a PC, you are stuck with serial TNCs (or a gateway DOS-PC) because you have a device driver problem or hardware alternative. Well, thanks to all who sent comments. There is no real need for a GPIB TNC. Still, it's fun to build one :-). Finally, from mikebw@uu.ids.net (Mike Bilow): > As I recall, HP was asserting patent rights on the three-wire handshake > used in IEEE-488? > [..] > I hope you are not the person assigned to collect the royalties! No. My statements here are purely private comments and have no connection whatsoever with HP's business interests. 73 de Jan, g0trr//dl5ue -- Jan Schiefer, g0trr, jas@hplb.hpl.hp.com, HP Labs Bristol, UK. +44 272 228344 Finally, I discovered a way to create lines longer then 80 columns, even on term ------------------------------ Date: Mon, 24 Jan 1994 11:00:02 -0800 (PST) From: Jeff Brown Subject: help understanding the division point of protocol vs app To: tcp-group@ucsd.edu Well, after that interesting subject, here is what I am seeking help on in english. I am the director of the Vodem project, which is an effort to deliver one-way internet news, email and FTP over cable TV, kinda like the satellite feeds, but at a hardware cost of about $150, and the cheapest monthly fee we can get from the carriers. Anyway, the vodem system can deliver a file or files one-way at over 90KBPS, but involves a proprietary formt and protocol. What I don;'t understand is where the protocols such as TCP/IP and UUCP end and the applications or agents for processing news and mail begin. In other words, where do I interrupt a normal SLIP/PPP/UUCP "feed" so that I can transmit the "feed" files over VODEM and have the individual user pick up the processing of the "feed". You can kind of think of the VODEM as a Kermit or ZMODEM type of thing - just for file transfer. Also, some help understanding how mail and news feeds are different over UUCP and TCP/IP (SLIP, PPP) would be greatly appreciated. I have searched many texts but can't find anything to help me burn off the fog if ignorance. Thanks in advance for all of the wisdom I am about to receive . Jeff Brown on Speedway Free Access -- (10288)-1-503-520-2222 jbrown@speedway.net ------------------------------ Date: Tue, 25 Jan 94 04:35:00 -0000 From: mikebw@bilow.uu.ids.net (Mike Bilow) Subject: help understanding the division point of protocol vs app To: tcp-group@ucsd.edu Cc: jbrown@speedway.net In a msg on , Jeff Brown writes: JB> What I don;'t understand is where the protocols such as TCP/IP JB> and UUCP end and the applications or agents for processing JB> news and mail begin. In other words, where do I interrupt a JB> normal SLIP/PPP/UUCP "feed" so that I can transmit the "feed" JB> files over VODEM and have the individual user pick up the JB> processing of the "feed". You can kind of think of the JB> VODEM as a Kermit or ZMODEM type of thing - just for file JB> transfer. JB> Also, some help understanding how mail and news feeds are JB> different over UUCP and TCP/IP (SLIP, PPP) would be greatly JB> appreciated. I have searched many texts but can't find JB> anything to help me burn off the fog if ignorance. Thanks in JB> advance for all of the wisdom I am about to receive. Oh my God... I don't know where to begin. Maybe something a little unusual, like Padlipsky's "The Elements of Networking Style," might be helpful. Padlipsky is something of an in-your-face controversial iconoclast, but he writes well and takes on this issue of how we divide things up. He has an axe to grind, which is that he hates the seven-layer model, but you don't even need to know that. This seven-layer model is pretty useful whether you think it is a good model or not, because it does give some ways of classifying the protocols. At the bottom layer, the "Physical Layer," you have protocols such as RS-232 and CCITT V.35, which define how device plug in and transfer groups of bits at a time. The next layer up, the "Link Layer," defines how two devices which are physically connected can have a logical connection for meaningful data flow; SLIP, PPP, UUCP-g, and Ethernet are all at this layer. At the third layer from the bottom, you have the "Network Layer," which defines how chains of devices communicating at the link layer can be strung together to give the illusion of an end-to-end connection; IP is the Network Layer protocol we play with here. The fourth layer up, the "Transport Layer," provides some way of moving more than individual blocks of raw data across the network, and of attaching some kind of agreed upon functional interpretation to them; TCP, UDP, ICMP, and their friends are all Transport Layer protocols. This model is open to a lot of criticism, especially as you reach the higher layers where it becomes very hard to define where the protocols separate. These kinds of issues often degenerate into religious warfare, and a number of protocols have been developed which do not fit neatly into this model. (For example, whether IP routing protocols live at the Network Layer or the Transport Layer is always good for a fight.) But the main principle here that no one would disagree with is the ultimate modularity of the protocol layers. Two hosts participating in an end-to-end TCP connection have no need to know whether the data is being passed over SLIP or Ethernet somewhere in the middle. Very high level protocols, such as SMTP, are supposed to be able to be designed only to interact directly with the public interface of the protocol immediately below, such as TCP. There are usually dependencies in practice, as when a mail circuit gets passed over a 7-bit network and 8-bit characters have to be accounted for (or prohibited). However, the design is such that SMTP need not be implemented differently over Ethernet than over SLIP. -- Mike ------------------------------ Date: Mon, 24 Jan 94 23:35 MET From: dc6iq@insl1.etec.uni-karlsruhe.de (Fred Baumgarten) Subject: ping-pong convers for Linux FTP site gone ? To: tcp-group@ucsd.edu (Advanced Amateur Radio Networking Group) : Date: Mon, 24 Jan 94 08:09:58 CET : From: BARRY TITMARSH : To: Fred Baumgarten , : Hi. Fred : Question whats happend to 129.13.109.160 the ftp site for ping-pong convers : is it closed ? its been not reachable for some time. or the ftp server : down. : Is there any new ftp site on the internet for anonymous ftp of the : ping-pong convers package. ? : Thanks.. : Barry.. No the site is still up and running ! It's just your domainiazed name which worries our security manager: your ip-addr -> hostname -> ip-addr != your ip-addr I can't help you, set up name server entries corretly and it'll work fine again ! 73, Fred PS: this conversd does _not_ work only in linux boxes... Comments welcome ! -- Fred Baumgarten [44.130.29.10] ------------------------------ Date: Mon, 24 Jan 1994 07:37:17 CST6 From: "Chris Cox W0/G4JEC" Subject: TCP MSS and TCP WIN settings To: tcp-group@ucsd.edu Jack, kf5mg wrote in a recent epistle: > Any idea how to tell what Interface a TCP socket is going to be > using? > 73's de Jack - kf5mg I don't see how you could tell. The determination of how a packet is routed is under the auspices of IP not TCP. It is quite conceivable, even on a radio circuit, that a packet (or rather stream of characters) which is queued, but not acknowledged, could be resent by a completely different path on each attempt at transmission. Naturally you can extrapolate this over the course of a socket-pair's life, and, therefore, you have no way of telling (except at some given instant by peeking at the routing table) how your session will be routed. Chris -- Chris Chris Cox W0/G4JEC chrisc@Central.NMMC.Mn.Org Network Analyst NIC Handle: CC345 North Memorial Medical Center Tel: (612) 520-7321 3300 Oakdale Avenue North Fax: (612) 520-5237 Robbinsdale, MN 55422 ----- For mail of a more social nature, please use ----- Internet: chrisc@moron.vware.mn.org Amprnet: chrisc@biggus.g4jec.ampr.org ------------------------------ Date: Mon, 24 Jan 94 15:00:58 GMT From: Alan Cox Subject: TCP MSS and TCP WIN settings To: CHRISC@Central.nmmc.mn.org, tcp-group@ucsd.edu This issue has been discussed a lot on the Linux developer lists of late and some suggestions were 1. Allow MTU/MSS settings per route for user configuration 2. Use 'Dont Fragment' and lower the mtu and resend on seeing such an error Alan ------------------------------ Date: Mon, 24 Jan 94 19:04:23 GMT From: Jan Schiefer Subject: TNC3s information To: tcp-group@ucsd.edu A number of people expressed their interest in the two TNC designs from Germany. I found some info about one of them, I'll keep digging for the other one. The following info is from the advert in the german ham magazine cq/DL, 1/94. - 15MHz 68302 processor in 16 bit mode - 64KB RAM, expandable to 1MB - real time clock - modems are puggable modules, 1200bps AFSK and 9600bps FSK (G3RUH) are currently supported - two modem ports can be used at the same time - modem interface is capable of 1Mbps - up to 115 kbps on the RS-232 - power supply 12V, 120mA (w/o modems) - ROM-Software: Firmware (similar to WA8DED), KISS, system test - software download to RAM possible - integrated mailbox software - connectors compatible to TNC2 I don't know whether they have distributors outside Germany, but it is worth giving them a ring. This is a commercial product, but Ulf is a real ham, so he should be open to weird&wonderful ideas. SYMEK GmbH Ulf Kumm, DK9SJ Johannes-Kraemer-Strasse 34 D-70597 Stuttgart Tel: +49 711 7654 911 Fax: +49 711 764564 German prices are DM490 for the CPU board in a nice box, DM75 for the 1200 and DM165 for the 9600 modem. RAM expansion to 256KB is DM40. I have no connection to the business of SYMEK and this posting is totally unrelated to my employer. 73 de Jan, g0trr//dl5ue -- Jan Schiefer, g0trr, jas@hplb.hpl.hp.com, HP Labs Bristol, UK. +44 272 228344 Finally, I discovered a way to create lines longer then 80 columns, even on term ------------------------------ Date: Mon, 24 Jan 94 10:13:09 mdt From: ka7oei@uugate.wa7slg.ampr.org Subject: Unclear about MTU in attach... To: tcp-group@ucsd.edu Perhaps something can be cleared up: On this gateway, the ethernet MTU is 1500... So, the TCP MSS, window, etc. settings reflect that. Since you can't set those things per-port, if someone on the air sets THEIR station up similarly (with MTU of 1500) then TCP will negotiate an MTU of 1500. (Any routers in the path are smart enough to accept a packet that big... not that it is encouraged to do that...) Ok. Since the MTU on the interface ATTACH command for the radio port is 256 bytes, what will actually happen? Is it smart enough to fragment the packet into small-enough pieces? I know that if one were to set the ethernet MTU to, say, 576 (in its attach command) but specify that it actually use 1500 byte packets, you will soon be faced with thousands of Ibuffails and a probable crash... Does a radio port behave the same way? (at least, a KISS port?) ka7oei@uugate.wa7slg.ampr.org ------------------------------ End of TCP-Group Digest V94 #21 ******************************